This specification relates to network access control.
Network access control involves regulating access to network resources based on a hosts' health, the identity of a user logged on to the host, or combination of both. As used herein, the term “host” refers to any computer device that is attempting to gain access to a protected network, or that has access to the protected network. A host can be a personal computer, a mobile communication device, a server computer in another network, or any other computer device capable of accessing the protected network. A network access control system protects a network by identifying, assessing, quarantining, and remediating host devices prior to network access and during network access.
The network access control system includes network sensors that are deployed on the edge of a protected network or within the network, and one or more network access control servers in data communication with the network sensors. The sensors detect new host devices attempting to gain access to the network and monitor host devices that have been granted access to the network. The sensors report to the network access control server(s) when new host devices are attempting to gain access to the network, and report actions taken by the host devices. The sensors can take actions with respect to a host device immediately, or can take actions with respect to the host device as determined by the network access control server(s), depending upon the health of the host device and the identity of the user that is logged onto the host device.
When a host device is first attempting to join a network, a sensor must collect information about the host device. Such host information collection is conducted during a host information collection phase. Each sensor has at its disposal one or more information probes that can be used to collect information from a host device. Furthermore, if the host device has installed upon it a network access control agent, the network access control agent can periodically provide beacons that include information about the host device. As there are several different types of information probes that the sensor can use to collect host information, determining how to effectively and efficiently send the information probes to the host device and process the replies can be challenging.
In addition, when a host device has been granted access to a network, the sensors monitor the host device for degradation of the host device health, for the logout of the user, and for when the host goes off-line and attempts to rejoin the network. Accordingly, the host device can go through multiple different states while attempting to access the network and after being granted access to the network. Determining how to manage the host device according to these various states is also challenging.
Additionally, in many network access control systems, sensors can be arranged in a failover configuration. In this failover configuration, a pair of peer sensors is used to control access to a network for host devices. One of the peer sensors is designated a primary sensor and the other peer sensor is designated a secondary sensor. To minimize network traffic, usually only one of the peer sensors is used to probe a host device, and the host status information received at the probing peer sensor is then provided to the non-probing peer sensor. However, one of the peer sensors may have a more reliable communication channel with the host device, or may have a communication channel that facilitates a more robust information probe than the other peer sensor. Accordingly, determining which of the peer sensors should be used to probe the host device can present the design challenge.
Furthermore, there are situations in which the probing peer sensor may be unable to communicate with the host device. For example, a firewall may be enabled that interferes with the probing peer sensors queries, or the host device may go off-line. How the pair of peer sensors responds to the probing sensor detecting the host going off-line can depend on the information probes that each peer sensor can use to probe the host device, and whether the primary peer sensor or the secondary peer sensor is the probing peer sensor. Accordingly, determining how the pair of peer sensors should respond to the probing peer sensor's failure to communicate with the host device should take into account these factors.
Each of the sensors stores a host table that includes a record for each host device that the sensor is monitoring. The record includes information such as the identity of the host, e.g., an IP address, or a MAC address, etc., the identity of the user logon to the host, e.g., a user identifier, and optionally other host device information. The host tables of the peer sensors are synchronized, as the probing peer sensor provides host device information to the non-probing peer sensor. In the event of one of the peer sensors failing, or in the event of a communication link between the peer sensors going down, the host tables of the peer sensors must be synchronized after recovery. As the status of the monitored host devices may have changed while a sensor was rebooting or while the communication link between the peer sensors was recovering, determining which host records in the host table need to be updated and which records do not need to be updated presents design challenges.
Finally, despite numerous security measures, there is always the potential for replay attacks. A replay attack is a form of a network attack in which information for credentials is delayed and/or fraudulently repeated at a later time. An attacker typically intercepts IP traffic to capture the credentials being transmitted from a host device, and then presents the credentials as their own. A common defense against a replay attack is the use of a nonce. For example, when a sensor provides an access portal to facilitate a user login from a host device, or queries an agent on the host device, the sensor will send a nonce to the host device when requesting authentication information, e.g., when requesting a user identifier and password within the HTTP 401 authentication realm, or provide a nonce with the agent query. The host device, in turn, sends a reply that includes an authentication code. When providing login credentials, such as a user identifier, the authentication code is a hash of the user's password and the nonce. The sensor then checks the authentication code by hashing the user's password and the nonce. Provided the hashes match, access is granted. Likewise, a reply to the agent query can include a hash that is, in part, based on the nonce. As the sensor provides a new nonce with each presentation of the access portal or with each agent query, replay attacks are thwarted.
Nonces are typically generated using pseudorandom number generators so that attackers cannot predict what the next nonce will be. However, use of pseudorandom number generators can be processor intensive. Additionally, the sensor may handle many authentication requests, and thus generating a new random number for each authentication request can be expensive in terms of processing resources.